โ RNS 1.4.2 released https://pypi.org/project/rns/
๐ฌค rns.recipes
top
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ rngit on a boat โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Started by bergie ยท 1mo ago ยท f9477df559d52317
Page 1 of 3
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-1
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ bergie #1 โ
โ f9477df559d52317 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 1mo ago
Greetings from the Tahanea atoll in French Polynesia!
We're two programmers long-term cruising with a small (<10m sailboat). On a trip like
this there are often times when we're held by the weather, and those are good
opportunities to work on our open source projects (NoFlo, various Signal K plugins).
The boat is powered by renewables (mostly solar, occasional help from a deployable wind
or hydrogenerator). With that we need to conserve energy and can't (and won't) run
Starlink all the time. Back in Europe we could fall back to an LTE uplink but here in
deserted islands that is not an option.
This makes the distributed development model as described by Reticulum manual a great fit
for us.
I have currently two rngit repository servers up: one running on the onboard Raspberry Pi
NAS, and another on an online VPS (adafb3153efd4d96d532568a5208b3b5), set to mirror the
repos from the boat.
Idea is that we can locally work with the boat-hosted repos, including managing work
documents and making releases. When the boat happens to be connected to the internet, our
VPS pulls the latest changes so they're available to others.
This works well, except for the fact that Work Documents (and Releases) are not mirrored.
The manual states that Release mirroring is planned, and so my question is whether it's
better to wait or to set up some temporary way to move the msgpack files over.
If we do so, is there anything to keep in mind except to place the files in the right
directories? Copying could maybe be done over rncp, though we also do have Syncthing set
up on both machines.
rngit is currently our only use of Reticulum. For messaging and alerting purposes in
these off-grid places we are using Meshtastic, where we have a relatively extensive setup
as documented here:
https://blog.noforeignland.com/off-grid-boat-communications-with-meshtastic/
Right now plan is to switch this setup also over to Reticulum RNodes, maybe around
November when we're settling in for the cyclone season.
โ 4 โ 0 โค 6
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-2
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ welo #2 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 1mo ago
out of curiosity cause this is a really interesting usecase, are you guys also using
rngit to distribute between Raspberry Pi and your own personal devices like laptops when
programming, and what interfaces are you using to connect them if so.
sorry I don't have anything to say about working with rngit, but I will say that having
rncp as a backup makes sense anyways because rngit is still new and having to make a bug
report at sea would suck
โ 2 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-3
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ bergie #3 โ
โ f9477df559d52317 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 1mo ago
welo wrote:
> out of curiosity cause this is a really interesting usecase, are you guys also using
rngit to distribute between Raspberry Pi and your own personal devices like laptops when
programming, and what interfaces are you using to connect them if so.
Development happens on personal laptops and on smartphones with Termux (rngit, rnsd etc
run quite nicely there!). Right now only TCP interfaces over internet or just the boat
WiFi. We have a stack of LoRa devices, and do carry Seeed T-1000e cards always with us,
but right now all of those run the Meshtastic firmware.
There are two things we need to happen to be able to go fully Reticulum:
Columba still needs to mature a bit. Though it isn't far! And preferably it'd be in an
app store (Play, or even better F-Droid).
The Meshtastic integration we have with our boat systems is critical. We control digital
switching over it ("turn decklight on") and get alerts ("anchor is dragging"). I'm
planning to port the signalk-meshtastic plugin to Reticulum and LXMF, but first I need to
sit down and get rns.js to a workable state. Signal K plugins need to run on Node.js.
I can see being able to push changes to our rngit repo from the beach over LoRa in the
future....
โ 2 โ 0 โค 1
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-4
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ p1ld7a #4 โ
โ 8279b6a997b08071 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 1mo ago
Interesting, on Android you can perhaps replace Columba with this app:
https://github.com/thatSFguy/reticulum-mobile-app or eventually Ratspeak
(https://github.com/ratspeak/Ratspeak). I found them both better and less batter-hunger
than Columba.
โ 0 โ 3 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-5
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Zenith #5 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 1mo ago
bergie wrote:
> welo wrote:
> > out of curiosity cause this is a really interesting usecase, are you guys also
using rngit to distribute between Raspberry Pi and your own personal devices like laptops
when programming, and what interfaces are you using to connect them if so.
>
> Development happens on personal laptops and on smartphones with Termux (rngit, rnsd etc
run quite nicely there!). Right now only TCP interfaces over internet or just the boat
WiFi. We have a stack of LoRa devices, and do carry Seeed T-1000e cards always with us,
but right now all of those run the Meshtastic firmware.
>
> There are two things we need to happen to be able to go fully Reticulum:
>
> Columba still needs to mature a bit. Though it isn't far! And preferably it'd
be in an app store (Play, or even better F-Droid).
>
> The Meshtastic integration we have with our boat systems is critical. We control
digital switching over it ("turn decklight on") and get alerts ("anchor is
dragging"). I'm planning to port the signalk-meshtastic plugin to Reticulum and
LXMF, but first I need to sit down and get rns.js to a workable state. Signal K plugins
need to run on Node.js.
>
> I can see being able to push changes to our rngit repo from the beach over LoRa in the
future....
Sideband has a telemetry feature with a very simple to develop on plugin system. It might
be exactly what you are looking for
https://github.com/markqvist/sideband
p1ld7a wrote:
> Interesting, on Android you can perhaps replace Columba with this app:
https://github.com/thatSFguy/reticulum-mobile-app or eventually Ratspeak
(https://github.com/ratspeak/Ratspeak). I found them both better and less batter-hunger
than Columba.
I haven't encountered any battery issues with Columba, and the power drain issues with
Sideband have been fixed for awhile. Running on my old A10e.
โ 1 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-6
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Zenith #6 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 1mo ago
https://github.com/markqvist/Sideband/tree/main/docs/example_plugins
โ 1 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-7
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Mark #7 โ
โ bc7291552be7a58f โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 1mo ago
Thanks Zenith :) I was about to mention that, but you beat me to it!
Sideband is really quite good for that kind of stuff. I use it for everything from
monitoring servers, controlling remote relays and devices, monitoring solar power
production and battery storage systems, controlling stuff in Home Assistant to viewing
remote security cams and getting news.
On Linux, you can run it in headless daemon mode, which is quite lightweight, and runs
fine even on small SBCs like the Pi Zero. You don't have to install it with all the UI
dependencies (or you can just use the AppImage).
Sounds like an amazing setup you have with the boat there :) At some point, I'm sure I'll
get to release and workdoc mirroring/syncing as well. For now, you can most likely make
it work by simply syncing the auxillary files over by any means that will work.
โ 3 โ 0 โค 3
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-8
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ bergie #8 โ
โ f9477df559d52317 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 1mo ago
Mark wrote:
> Sideband is really quite good for that kind of stuff. I use it for everything from
monitoring servers, controlling remote relays and devices, monitoring solar power
production and battery storage systems, controlling stuff in Home Assistant to viewing
remote security cams and getting news.
That sounds very close to the use case we have with monitoring the boat. Now we get
telemetry via Meshtastic using their somewhat limited [telemetry
schema](https://buf.build/meshtastic/protobufs/docs/5f00ad5691ae7d8a03fd92437b81e9a424e348
3f%3Ameshtastic#meshtastic.EnvironmentMetrics). Meshtastic is transitioning from a push
model to a pull model on telemetry, but for now our boat still transmits every 10min.
I have to admit I'm a little confused on how the telemetry functionality in LXMF is
supposed to be used. There's mentions of telemetry collectors and such, but not a lot of
examples. I was planning to post a question on that here once I get a bit further (now
rns.js crashes when it receives an LXMF message, so there's some basic shoveling to be
done before I can start integration).
In addition to text commands, I've been thinking an authenticated NomadNet interface
might be interesting to see status of things and to control stuff like digital switching.
> Sounds like an amazing setup you have with the boat there :) At some point, I'm
sure I'll get to release and workdoc mirroring/syncing as well. For now, you can
most likely make it work by simply syncing the auxillary files over by any means that
will work.
Thanks! And thanks a lot for writing the Distributed Development chapter, that got some
gears rolling on my head. If things work out (and there are enough rainy days to code), I
might release some tooling related to that and NoFlo.
Offline-first is really the only way that works in situation like ours. And centralized
providers like GitHub are proving to be quite problematic.
For copying work documents, I guess I'll do the following:
โข On our NAS we have a systemd timer to periodically make a tarball of the work docs
โข The VPS periodically pulls the latest tarball over rncp, unpack, and puts the files
in the right places
This is obviously one-way sync, so proposed work docs from third parties aren't possible.
But it would be a start. And right now there are no interested third parties anyway.
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-9
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ welo #9 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 1mo ago
I will additionally note that [it is possible to push reticulum traffic through
meshtastic](https://codeberg.org/Firespark/RNS_Over_Meshtastic) if you happen to have
meshtastic infrastructure either internally or externally that you cannot replace. There
is some overhead but it's not terrible.
โ 0 โ 0 โค 1
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-10
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ bergie #10 โ
โ f9477df559d52317 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 1mo ago
welo wrote:
> I will additionally note that [it is possible to push reticulum traffic through
meshtastic](https://codeberg.org/Firespark/RNS_Over_Meshtastic) if you happen to have
meshtastic infrastructure either internally or externally that you cannot replace. There
is some overhead but it's not terrible.
Oh, that is certainly interesting! We have a good set of Meshtastic infrastructure now,
including a well-situated solar-powered repeater on the mast. Intention is to keep some
Meshtastic still around even when we switch to Reticulum - at least the boat node and the
repeater. Reticulum LoRa will get its own transport node on the other spreader.
It is a shame Meshtastic allows only one connection to a device at a time, so one will
need to stop the Meshtastic app to use this transport. I've been thinking it would be
possible to write a multiplexer, but maybe that effort is better spent elsewhere.
In any case, this would allow some experimentation with Reticulum-over-LoRa before we
have the actual RNode infrastructure up.
If we go discoverable on the Meshtastic interface, would it show up on
the maps?
Which reminds me, the [discoverable interfaces
spec](https://reticulum.network/manual/interfaces.html#interfaces-discoverable) has fixed
lat and lon to be set in the rnsd config. That obviously isn't ideal for migratory
Reticulum instances like ours. It might be nice if Reticulum supported a shell script to
get current location like it does for IP in reachable_on .
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Page 1 of 3
โ INFO โ Identify to this node to post. How?
bottom